fix: LMOTS pattern, add HSS variant (LMS family) - #1029

Also added HSS, which was missing entirely. It's just the multi-level LMS construction, parameterized by number of levels (L), so the pattern is intentionally minimal — no hash/M/H, since those come from whichever LMS parameter set each level uses.

Would there be any way to express that? Dependencies?

Note for reviewers, RFC 8554 explicitly allows a lot of flexibility:

We specifically allow different LMS levels to use different parameter
sets. For example, the 0-th LMS public key (the root) may use the
LMS_SHA256_M32_H15 parameter set, while the 1-th public key may use
LMS_SHA256_M32_H10.

Hi,
@jvdsn thank you for reviewing this PR.
In this schema, variant only has pattern/primitive/standard, no dependency field, so there's no structural way to express this today. XMSSMT handles its multi-tree case by encoding {h}/{d} directly in the pattern string, but that only works because XMSS-MT levels share one parameter set. HSS can't use the same trick since RFC 8554 allows each level to pick an independent LMS parameter set. Left HSS[_L{levels}] as-is for now — a real fix would need a schema change to support per-level composition, which is bigger than this PR. (For what it's worth, I also checked the v2 cryptography schema — it moves to a free-text parameterSetIdentifier per algorithm instance rather than family-level patterns, and doesn't add a composition mechanism either, so this looks like a genuine open gap rather than something already solved elsewhere.)
Happy to adjust further if maintainers have thoughts on this — let me know if any additional changes are needed here.

If I understand correctly, we would like to describe an ordered sequence of LMS parameter sets for HSS, one per level, including the associated LMOTS parameter sets. Is that correct?

What we could do is extending the naming-pattern convention to support repetition. For example, * for zero or more occurrences or + for one or more, and references to other patterns, such as <LMS> and <LMOTS>.
This would require documenting the new notation, but no structural change to the JSON schema, since pattern is already a string. It could keep this within the existing naming-pattern approach.

Yes, that’s exactly it — HSS is an ordered sequence of L levels, each with its own LMS and LMOTS parameter set (RFC 8554 secion 6; SP 800-208 narrows the allowed sets but keeps the per-level structure).

I like extending the naming-pattern notation rather than changing the schema. Three things I’d want covered when we document it:

• is already a literal in SPAKE2+…. Either restrict quantifiers to follow a ) group only, or define an escape.
  needs a resolution rule: a reference to the variant pattern whose leading literal is LMS (not the family — the LMS family also holds LMOTS), with leading literals unique across the registry.
  The pattern can’t tie the repeat count to {levels}; that would be a stated rule, like the join rule in CBOM: add protocol registry schema #1010.
  Something like HSS[L{levels}][(_)+], root level first.

Since this touches the convention for the whole registry, do you suggest keeping this PR as the LMOTS/HSS correctness fix and doing the notation + full HSS pattern as a follow-up (happy to open it). Fine to fold it in here instead if you prefer. @bhess